Traditional computing environments were often populated by mainframe computers such as the IBM 3270, and, eventually, mid-range computers, such as the IBM AS400. Over the years, many companies made huge investments into these platforms, which were notoriously good at providing very large, complex applications, such as accounting, general ledger, and inventory systems for running businesses of all sizes, and vertical applications which were developed to run in optimized form in these host computing environments. Initially, users of such programs used wired terminals to directly communicate via “sessions” with these host environments. A user could create a secure session to communicate with an application running on the host computing system by presenting credentials (e.g., username and log-on information) to the host via the terminal for authentication and authorization. The application would run on the “host” computing system, receive input from the user terminal via a session, and forward output back to the terminal via a session for display. All communication between the terminal and the host computing system was done through sessions. Because the screens of such terminals were traditionally black with green writing, the output from host applications (also referred to as “legacy” applications) were affectionately known as “green screens.” FIGS. 1A and 1B are example screen displays of “green screen” legacy application output as presented by such prior systems. There was no direct manipulation or pixel addressing present, the data stream was a typically 80-character stream presented line-by-line on the display screen.
Legacy applications can be typically characterized by their voluminous number of menus, their hierarchical access nature, and their session-driven state. For example, in a legacy application it is quite typical for an end user to select upwards of 10 or more menus, each corresponding to a separately executable task, to get to a point in the system where the user can enter some data, for example in an accounting form, only to need to back all the way out and enter another set of 10 or menus to obtain some related data, for example, a part number of an inventoried item in an inventory system, and then need to reenter all of the first set of 10 or more menus to get back to where the user was originally entering the accounting data. In a single session, this can happen hundreds if not thousands of times. Moreover, to do multiple things at once, for example, to handle the same data entry for multiple customers at a time, each requires a separate session. Thus, it is easy for a user to lose context and become frustrated.
As desktop and personal computing became more mainstream, terminal emulators, designed to run, for example, in windowed environments on a personal computer (PC) and using the Internet, replaced the hard wired terminals. These PCs terminal emulators, emulating the terminals, thus continue to communicate via sessions with the legacy applications running on these host systems. The end user runs each application in a session managed by the terminal emulator, and legacy output is returned to the emulator. The emulator typically presents the green screen equivalent within the confines of the emulator display, often a window. FIGS. 2A and 2B are example screen displays of the same “green screen” legacy application output presented by a terminal emulator.
Overtime, as graphical user interfaces (GUIs) became an expectation, and not just a nicety, increased modernization of the “green screen” was made available. In particular, the interfaces presented by the terminal emulators were made smarter so that some amount of enhanced graphics and visuals could be delivered to interface to these legacy applications. For example, commands could be accessed by checkboxes instead of numeric input, menus could be directly selected, etc. FIGS. 3A and 3B are example screen displays of recent modernization of “green screen” legacy application output as performed in current systems. Even though the user interface is potentially more user-friendly, the underlying host applications still require access through the multitude of menus and via sessions. The protocol remains of sign on, create a session, run one or more jobs, sign off, as many times as needed to accomplish the user's objective.
As a result, although computing resources have become cheaper, and many mid-range computing systems like the AS400 have replaced the old mainframe hardware in many companies, the legacy applications continue to have their strong place in everyday use, especially in larger or geographically distributed companies, such as companies with many branch offices. This phenomenon is due in a large part to the investment that has been made over the years to greatly expand the capabilities of such applications and to tailor the applications for a particular company's use. Customizations may take hundreds of thousands of person-hours and such applications are typically rewritten, regenerated, and redistributed each time a new function or customization is needed. Thus, in instances in which companies have invested large amounts of money and resources, it may make more business sense to continue to run the legacy application rather than convert to another, more modern, tool. Often times it is both cost and time prohibitive to do so.